Unless you have a very good reason, do not catch Exception, ever (a vast array of bugs in real systems come from this seemingly innocuous block).
Instead, handle any specific exceptions you can, declare any checked exceptions necessary, and let callers handle things from there.

The try-catch here would probably be greatly reworked or removed from here. This was done just to help develop the core functionality.

Builder constructors should not, in general, take parameters. The whole point of a "builder" is to start empty and set each value as needed (chained by returning the builder from each set method) before a build produces the result value.

What you've written here is an oddly structured factory, rather than a builder.

I agree about the builders, in fact, I prefer to implement Joshua Bloch's builder where we have Builder class that is internal to the class we want to build, since we can access directly the private filed of the internal builder from the target class and pass the builder itself as a constructor parameter.

I also agree that the builder should start "empty" and we set each value as needed.

I do not agree however that the builder constructor or static method that gets us the builder instance should have no arguments. There are some things that are mandatory for the given instance that will be constructed. Without forcing the caller to supply them, it is very error prone. The optional stuff should be settable later.

In our case it really looks like an odd factory, in fact I was thinking if we need the builders at all, we could just have static of() or from() or similar method directly inside the target class and omit the builders. The only place where we currently have an optional value is the folderPermissions which I will remove the possibility to be set externally, they shall remain an internal property of the class. All other builders are in the same fashion.

There are two views here in my opinion.

1. We simplify and remove the builders as they are not needed at all at this point, no need to support them.
2. We keep the builders as they are with the thinking that if in the future will appear optional dependencies they will be introduced within the builder as setters and our refactoring will be minimal.

UNRELATED SIDE NOTE: In some rare cases where we have a very complex building logic that requires some things to be set before others or when setting something then we must proceed with additional settings for what we just set, then I like to do interactive builders where I have multiple interfaces with specific setters and my builder implements all giving me the possibility to guide the caller through the possible options at any given step, returning a specific interface. (not applicable at all to us, just an interesting side note)

Thank you for the well reasoned reply. Here are my thoughts.

1. Removing the builders and using a static of method makes sense in these small-value cases where you want all the required values set. My comment was that a constructor, specifically, should not have parameters; a static method is a secondary pattern (builder-factory-method), and it is fine to have parameters (in fact practically required) there.
   • It also makes sense to have a builder that is properly designed, internal to the class to build, and accessible only as a return value from an of method that takes the required parameters; this also avoids the perceived need to have a constructor with parameters while retaining regular "builder" semantics.
2. Re: the side note, I am not a huge fan of interactive builders with multiple interfaces (I've seen that become a nest of bugs that breeds more too many times). If there is an ordering or containment requirement, the intent of a builder would, in my opinion, be to remove the ordering/containment requirement and allow values to be set in any order, but then apply them to the created object in the correct order and containment during the build method. A build method might, in this setup, construct an entire tree of objects in order to meet all the requirements for a particular highly complex object build.

@jsync-swirlds awesome! Thanks also for your insights! I like the combination of the of method that will get us an internal builder. I will implement that, it will clean up a lot of things! Just so that there is no confusion on my side:

1. Do you propose that I will now remove the external builders and have a static of method that will be part of the target class, from where we will supply all mandatory dependencies AND since there are currently no cases (or will not be once I remove the folderPermissions) of optional dependencies, the of method alone is sufficient. Once we have an optional dependency for the given class, the of method will then return a newly made internal to the target class "Joshua Bloch" style builder and it will be an easy refactor.

OR

2. Same as above, I remove the external builders, have an of method in the target class, but proactively create the internal builders and simply call the build method where I want an instance of the target class, despite the fact that currently we have no optional deps.

?

In any case, I am generally pro for static instance creation methods.

Let me know, thanks again, insightful thread! :)

I would recommend starting with option (1), and we can always adjust later if needed.

✅ Done. Quite the refactoring it was, took a while, but everything is a lot cleaner :). One note, for the places where are no input params, I have used the method name 'newInstnace', the name 'of' and then passing nothing really did not fit at all. Since now everything is wired, a simple rename of all usages of 'newInstance' is trivial and takes milliseconds.